Because we want the content we deliver to be signed so the student won't run just any any content, and so some one can't trick the student into running bad content. Also we want a full access control system. Because we are on unsecure local storage, we need an elaborate key system.

Requirements

• unsecure local storage
• school should ave option to limit what content a student can view/run
  • this limit could be flexible like the java security model, so a student could run untrusted content but that content would be in a restricted area
• content developers, teachers should be able to prevent students from seeing some content at all.
• students should be able to author content that other students can't see.
• students should be able to atuhor content that teachers are prevented from seeing.
• students should be able to author content that they share with groups of other students. These members of these groups can edit this content.
• some content should be read-only.
• the permissions system should be extendable while the user not connected to a trusted server, but is talking to a peer device.

Implementation

• Every user will have a public and private key pair.
• The public key for every user will be avaialbe in a file signed by a trusted source (concord or the school)
• The private key will be encypted with the users password and will be in a file signed by a trusted source.
• the trusted source public keys will be stored in an area where students cannot change them. To update these "root" keys an admin will have to log into the computer. This will only work on windows systems with ntfs file systems, it should be fine on linux and osx. For fat file systems we can't do much. The trusted source public keys could be verified when the system is online to check for tampering.
• students will also have reversible encryption keys. There will be two sets of these keys for a student. Verified keys and non-verified keys. Bot sets of keys will be stored encrypted with the users prublic key. The verified keys will be in a file signed by a trusted source. The non-verified keys will be unsigned.
• the student will also have a set of public and private keys for each group they are in. There will be verified and non-verified sets of these keys.
• content on the disk will be in a few different states:
  • unencrypted and signed - it can be signed by a: student, content company, group, teacher, school
    this content is technically readable by anyone. However the system might prohibit a user from opening it. (running or view) in other words if the storage file was examined by a text editor they could see the content but they couldn't use the system to open the conent.
  • encrypted and signed - it can be signed by the same authors as above, but in this case it will be encrypted so only users that have access to the key can see it. This should be fully secure even if the computer was hacked into.

Issues

• sharing existing content with other users or groups. If one peice of content needs to be editted by two non-intersecting groups, a new key would need to be made just for those groups. Basically what it means is that only one key can own a piece of content at a time. This only hold for content that needs to be writable by users.

what two keys were used to sign some content. How do I verify who should have signed which pieces of content. If the top level dependancy file is signed by a trusted source then this would be one way. I guess it could say that it is valid for either group to sign the content.

so what happens when a new piece of content is created by a group? How is the access controlled?